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(54) System for providing a trustworthy user interface 



(57) The preferred embodiment of the invention 
comprises a computer system which employs a trusted 
display processor (260), which has a trusted processor 
(300) and trusted memory (305, 315, 335, 345) physi- 
cally and functionally distinct from the processor and 
memory of the computer system. The trusted display 
processor (260) is immune to unauthorised modification 
or inspection of internal data It is physical to prevent 
forgery, tamper-resistant to prevent counterfeiting, and 



has crypto functions (340) to securely communicate at 
a distance. The trusted display processor (260) interacts 
with a user's smartcard (122) in order to extract and dis- 
play a trusted image, or seal (1000), generate a digital 
signature of the bitmap of a document image and control 
the video memory (315) so that other processes of the 
computer system cannot subvert the image during the 
signing process. The user interacts with the trusted dis- 
play processor via a trusted switch (135). 
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• Each entity is confident that the other entity is in fact the entity which It purports to be; 

• Where one or both of the entities represent a party to a transaction, e.g. a data transfer transaction, because of 
the in-built trusted component, third party entities interacting with the entity have a high degree of confidence that 

5 the entity does in fact represent such a party; 

• The trusted component increases the inherent security of the entity itself, through verification and monitoring proc- 
esses implemented by the trusted component; and 

10 • The computer entity is more likely to behave in the way it is expected to behave. 

[0008] While the concept of a trusted component as described in the co-pending application goes a long way to 
providing to a user with a substantial degree of trust in a computer platform, there are still times when the user requires 
an even higher degree of trust in his equipment, for example during an electronic transaction, such as cSgitally signing 
is a document, or transferring funds from the platform to a remote platform. 

[0009] As has been indicated above, the conventional method of signing a document is to physically write a signature 
on the medium (usually paper) upon which an image of a document is reproduced. This method has the advantages 
that it is clear what is being signed, and the signed image is proof of what was signed. However, It does not meet the 
needs of e-commerce. 

20 [001 0] Nowadays it is also possible to digitally sign a document using a conventional compuler platform and standard 
encryption techniques. In conventional computer platforms, however, the present inventors have appreciated that the 
electronic rendition of a document which is digitally signed is typically not the same rendition of the document that is 
visible to the user It is therefore possible for a user to unintentionally sign data that is different from that which he 
intended to sign. Conversely, it is also possible for a user to intentionally sign data and later fraudulently claim that the 

is signed data does not correspond to that displayed to him by the computer platform. Such problems would stll bo the 
present, even if a trusted platform, as described above, were used. 

[0011] Conventional electronic methods of signing are well known to those skilled in the art. Essentially, digital data 
is compressed into a digest, for example by the use of a hash function. Then that digest is encrypted by the use of 
some encryption method thai has been initialised by a secret key (or simply a 'secret*). This is normally done on a 

so computer platform, such as a PC. One implementation is to sign data using a private encryption key held secret on a 
user's smartcard. which is plugged into a smarlcard reader attached to the computer platform. In the specific case of 
a textual document, the digital data may be the file produced by a word processor application, such as Microsoft's 
Notepad, Wordpad, or Word. As usual, the act of signing implies that the signer accepts some legal responstoilrty for 
the meaning of the data that was signed. 

as [0012] Hash functions are well-known in the prior art and comprise one way f unctions which are capable of generating 
a relatively small output data from a relatively large quantity of input data, where a small change in the input data results 
in a significant change in the output data. Thus, a data file to which is applied a hash function results in a first digest 
data (the output of the hash function). A small change e.g. a single bit of data in the original data file will result in a 
significantly different output when the hash function is reapplied to the modified data file. Thus, a data file comprising 

40 megabytes of data may be input into the hash function and result in a digital output of the order of 128 to 160 bits 
length, as the resultant digest data. Having a relatively small amount of digest data generated from a data file stored 
in the reserved directory is an advantage, since It takes up less memory space and less processing power in the trusted 
component. 

[0013] During known signing processes, a user will typically interpret a document as it has been rendered on the 
<s computer's monitor at normal magnification and resolution. In existing applications, the user's smartcard signs data in 
a format that is the representation of the document by the application used to create and/or manipulate the document. 
The present inventors believe, however, that there is potential for software to send data to the smartcard that has a 
different meaning from that understood by the user when viewing the screen. This possibility may be sufficient reason 
to introduce doubt into the validity of conventional methods of digitally signing electronic representations of documents 
so that are to be interpreted by people. 

Disclosure of the Invention 

[001 4] The present invention aims to provide a user with greater trust during a trusted operation by providing a trusted 
55 user interface. 

[001 5] In accordance with a first aspect, the present invention provides a data processing systemcapable of operating 
in a trusted operating mode, the data processing system comprising: 
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Best Mode For Carrvino Out the Invention, & Industrial Applicability 

[0021] The preferred embodiment utilises a trusted component that most conveniently uses some of the character- ' 
istics of the trusted component 1 described in the applicants copending European patent application number. 
5 99301 1 00.6. In that application, the trusted component is a hardware device, comprising a processor programmed to 
measure an integrity metric of its host computer, compare it with a true value of the integrity metric and communicate 
the integrity (or otherwise) of the host computer to users or other host computers. The significant similarities between 
that trusted component and the trusted component in the preferred embodiment herein are: 

io that they both use cryptographic processes but preferably do not provide an external interlace to those crypto- 
graphic processes; 

that they are both tamper-resistant or tamper-detecting, so that their operation cannot be subverted, at least without 
the knowledge of the legitimate user; and 

that they both preferably consist of one physical hardware component that is both physically and functionally m- 
is dependent ol the host computer on which it resides. 

[0022] Such independence is achieved by the trusted component having its own processing capability and memory. 
[0023] Techniques relevant to tamper-resistance are well known to those skilled in the art ol security, as described 
in the applicant's co-pending application. These techniques include methods tor fabricating components to resist tam- 

20 pering. methods lor delecting tampering, and methods lor eliminating data when tampering is detected, it will be ap- 
preciated that, although tamper-proofing is a most desirable feature ol the present invention, it does not enter into the 
normal operation of the invention and, as such, is beyond the scope of the present description. 
[0024] In this description, the term trusted 1 , when used in relation to a physical or logical component or an operation 
or process, implies that the behaviour thereof is predictable under substantially any operating condition and highly 

25 resistant to intorf oronce or subversion by external agents, such as subversive application software, viruses or physical 
interference. 

[0025] The term fiost computer 1 as tsed herein refers to a data processing apparatus having at least one data 
processor, at least one form of data storage and some form of communications capability for interacting with external 
entities, such as peripheral devices, users and/or other computers locally or via the Internet. The term 'host computer 
so system 1 in addition to the host computer itself includes standard external devices, such as a keyboard, mouse and 
VDU. that attach to the host computer. 

[0026] The term , document , . as used herein, includes any set of data that can be visualised using a host computer 
system. Commonly a document will be a textual document, such as a contract. However, a document may comprise 
graphics, or pictures, instead of. or as well as, text. In general, a document may comprise a single page or multiple 
os pages. 

[0027] The term 'pixmap', as used herein, is used broadly to encompass data defining either monochrome or colour 
(or greyscale) images. Whereas the term 'bitmap* may be associated with a monochrome image only, for example 
where a single bit is set to one or 2ero depending on whether a pixel is on 1 or 'off, 'pixmap 1 is a more general term, 
which i encompasses both monochrome and colour images, where colour images may require up to 24 bits or more 

40 to define the hue, saturation and intensity of a single pixel. 

[0028] As will become apparent, the trusted component according to the preferred embodiment herein provides a 
secure user interface and, in particular, controls at least some of the display functionality ol its host computer. The 
trusted component herein may or may not also acquire integrity metrics according to the trusted component in appli- 
cant's co-pending patent application, although such acquisition of integrity melrics will not be considered herein. 

45 [0029] In essence, the preferred embodiment enables a user to digitally sign a document stored on a host computer 
using the private key of the user's smartcard. or other form of secure token such as a cryptographic cc-processor. The 
signing is enacted by a trusted display processor (i.e. the trusted component) of the host computer under conditions 
that provide the user with a high level of confidence that the document being viewed on screen is in facl the document 
the smartcard is signing. In particular, the smartcard carries trusted image data, or a 'seal', which is passed to the host 

Si? computer over a secure channel and displayed by the trusted component during the signing procedure. It is in part the 
display of the trusted image, which is typically unique to the user, which provides the user with the confidence that the 
trusted component is in control of the signing operation. In addition, in the preferred embodiment, the host computer 
provides a trusted input device, connected directly to the trusted display processor, by which the user can interact with 
the host computer in a manner which cannot be subverted by other functions of the host computer. 

ss [0030] More particularly, the trusted display processor or a device with similar properties is associated with video 
data at a stage in the video processing beyond the point where data can be manipulated by standard host computer 
software. This allows the trusted display processor to display data on a display surface without interference or subver- 
sion by the host computer software. Thus, the trusled display processor can be certain what image is currently being 
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of this is that the trusted display processor may '^W^J™^ mguagM or prompts. 
[0031] rtwillbe appreciated t^t.^let^ 

the concept ot providing a trusted user interface is far more i oroaory pp 1(an8action . 

his host computer ^«^Sff^ h ^ W ^ 
[0032] Figure 1 illustrates a host ^^ e, ^^^^^^ opeteXing system. According to Figure 1 , the 
s a Persona. Computer, or POwhfch J^oSX- "° a 0101)86 115 8 "T22 

host computer 100 is connected »*^g^J^Z^*to Internet 130. Herein, the smarted 
reader 120. and a local area network (LAN) 125, when in rum i is eu kevboard | n addition, the host, computer has 

»Sl»tSSS !! ''-''• l --- ,, ■" 

jssrw- 1 «. • ^ — srs - « • - -a 

[0034] According to Figure 2. the host computer ROM2lO,aB of which are mounted on a motherboard 

Lor conr^totnalnmem^ <£*X7T^^%^ *o*™. The CPU is connected via a PC. 
215 ol the host computer 100. The < JJ^TpS bwSto which are attached the other rnain componerts 
(Peripheral Component Interconnect) badge 220 to a PCI ™ C V T d ^ portions, which will not be 
of the host compter 100. The bus 225 comprises W^^^^a archSecturee. which is beyond 
described in detail herein. For a detaled ^^^Z E?£SU"-»* PC Hardware Handbook', 
the scope of the present description, the reader » •J^J^* BN 0-201-40399-4. a course, the present em- 
3rd Edition, by Hans-Peter Messmer. published by Af""^*^ vWndowe™ operating systems or PCI buses. 
Limentteinnowayl^edtoimplementa,^ ^^ inc.ude: a SCSI (smal. 

[0 03S] The other mam components of **^^^SSm disk drive 240 and a CW»M drtve245; 
computer system interface) adaptor connected via a ^f^ 8 j^° 100 , 0 a LAN ! 25. via which the host computer 
S (local area network) adaptor 250. or ^s fttese^ers. print servers or email servers, and 

10 0 can communicate with other host ^^^^Z ZZ™> "0. mouse 115and smartcard reader 

,he internet 1 30; an IO ^^^^ZZSl^^^ a " 8tendard ^ ft! 
120; and a trusted display processor 260. The ^^™*^!rL ndard functions' are those functions that 

display processor 260. HtarJiw nrocessor 260, are prelerably also integrated onto 

«!Lu> con,*™* P««*9 ^S?E2SK *L P«~< «■ aw™*" 

a microcontroller 300; . • in _ rfl « Dec tive control program instructions (i.e. 

graphfcs prknHives) from the CPU 200 ^^tr^ed^9-^a <™ ^ ^ ^ ^ ^ M 

, ra me butler memory 315^ which ^"J^^^JX**** resolutions of 1280x768 supporting up 
frame (a typical frame bufler memory 31 5 is 1 -2 Mbytes in size, .or so «* 
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to 16.7 million colours); , ' . . 

a video DAC (digital to analogue converter) 320 for converting pixmap data into analogue signals lor driving the 
(analogue) VDU 105, which connects to the video DAC 320 via a video interface 325; 
an interface 330 for receiving signals directly from the trusted switch 1 35; 

s volatile memory 335, for example DRAM (dynamic RAM) or more expensive SRAM (static RAM), for storing state 

information, particularly received cryptographic keys, and for providing a work area for the microcontroller 300; 
a cryptographic processor 340, comprising hardware cryptographic accelerators and/or software, arranged to pro- 
vide the trusted display processor 260 with a cryptographic identity and to provide authenticity, integrity and con- 
fidentiality, guard against replay attacks, make digital signatures, and use digital certificates, as wiH be described 

io in more detail below; and 

non-volatile memory 345, for example flash memdry, for storing an identifier 1^ of the trusted display processor 
260 (for example a simple text string name), a private key Spp of the trusted display processor 260, a certificate 
Cert 0P signed and provided by a trusted third party certification agency, such as VenSign Inc.. which binds the 
trusted display processor 260 with a signature public-private key pair and a confidentiality public-private key pair 

is and includes the corresponding public keys of the trusted display processor 260. 

[0039] A certificate typically contains such information, but not the public key of the CA. That public key is typically 
made available using a Public Key Infrastructure' (PKI). Operation of a PKI is well known to those skilled in the art of 
security. 

20 10040] The certificate Cert DP is used to supply the public key of the trusted display processor 260 to third parties in 
such a way that third parties are confident of the source of the public key.and that the public key is a part of a valid 
public-private key pair. As such, it is unnecessary for a third party to have prior knowledge of. or to need to acquire, 
the public key of the trusted display processor 260. 



25 



the public Key or ine trusieo oispiay processor 

10041] The trusted display processor 260 lends its identity and trusted processes to the host computer and the trusted 
display processor has those properties by virtue of its tamper-f esistance. resistance to forgery, and resistance to coun- 
terfeiting. Only selected entities with appropriate authentication mechanisms are able to influence the processes run- 
ning inside the trusted display processor 260. Neither an ordinary user of the host computer, nor any ordinary user or 
any ordinary entity connected via a network to the host computer may access or interfere with the processes running 
inside the trusted display processor 260. The trusted display processor 260 has the property of being "inviolate* 
30 [0042] Originally, the trusted display processor 260 is initialised with its identity, private key and certificate by secure 
communication with the trusted display processor 260 after it is installed onto the motherboard of the host computer 
100. The method of writing the certificate to the trusted display processor 260 is analogous to the method used to 
initialise smartcards by writing private keys thereto. The secure cjorrimunications is supported by a 'master key\ known 
only to the trusted third party (and to the manufacturer of the host computer 1 00), that is written to the trusted display 
35 processor 260 during manufacture, and used to enable the writing of data to the trusted display processor 260. Thus, 
writing of data to the trusted display processor 260 without knowledge of the master key is not possfele. 
[0043] It wilt be apparent from Figure 3 that the frame buffer memory 31 5 is only accessible by the trusted display 
processor 260 itself, and not by the CPU 200. This is an important feature of the preferred embodiment, shce it is 
imperative that the CPU 200, or, more importantly, subversive application programs or viruses, cannot modify the 
40 pixmap during a trusted operation. Of course, it would be feasible to provide the same level of security even rf the CPU 
200 could directly access the frame buffer memory 315, as long as the trusted display processor 260 were arranged 
to have ultimate control over when the CPU 200 could access the frame buffer memory 315. Obviousry, this latter 
scheme would be more difficult to implement. 

[0044] A typical process by which graphics primitives are generated by a host computer 1 00 will now be described 
45 by way of background. Initially, an application program, which wishes to display a particular image, makes an appro- 
priate call, via a graphical API (application programming interface), to the operating system An API typically provides 
a standard Interface for an application program to access specific underlying display functions, such as provided by 
Windows NT™, for the purposes ol displaying an image. The API call causes the operating system to make respective 
graphics driver library routine calls, which result in the generation of graphics primitives specific toa display processor, 
so which in this case is the trusted display processor 260. These graphics primitives are finally passed by the CPU 200 
to the trusted display processor 260. Example graphics primitives might be 'draw a line from point x to point y with 
thickness t or Till an area bounded by points w. x, y and z with a colour a'. 

[0046] The control program of the microcontroller 300 controls the microcontroller to provide the standard display 
functions to process the received graphics primitives, specifically: 

receiving from the CPU 200 and processing graph ics primitives to form pixmap data which is directly representative 
of an image to be displayed on the VDU 105 screen, where the pixmap data generally includes intensity values 
for each of the red. green and blue dots of each addressable pixel on the VDU 105 screen; 
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to display the required image on lh? screen, 
luuwj v _ trusted image data to form a singie p»"»h 

00471 The trusted display processor 260 forms a part of J .^,,80. by application programs and 

Earthly *■*» ,uncti0nS °' TroSpTSssS TnSe ™ 1 05. In 5m words, the "display . 

S^As already n-«* present ^^^^TSTZTJS^^ 
S^tteuse^ smartcard 122. The processing en ^ e °' a ^ 

^e^mtUen, is Heated In ^^S^X^^^ * T^JS 
encryption and decryption Junctions, to support ^^^^e^mue,. which has a built-in operating 
Sere. In the present embedment ^^^^^^aSS^ P«*«*** specified through 
system and is arranged to commun«ate wfth ^f^^J non ^a,ite memory 420. tor 
7 8 16 . 3 , 4 . T=0. T=1 and T=14 standards^ ™«™°f" ~^e key Ssc. used tor digitally signing data, and a 
memory, containing an identiier Isc J^^'^^^SbWe .he smartcard with pubttc-pnvate 
™* raf . orovided by a trusted third party certification agency, wn the certificate Certpp 

ousted display processor 260). Further, the "J^S^SiS?* to *• UMr ^ 8 1 

which can be represented graph.ca.ly by the trusted d, ^SS!mS,^ ,n the present embodiment, the seal 
operating secure* with the user's smartcard. as w* be descnb ec hn de me osef as a unique Wentifier, for 

SEAL is in the form of an image Wjf^ 
example an image o, the user himself. ^^"^^^ Sng state Wormatton (such as received keys) 

sees— s:.— 

San? B e in cLmstances where the hj. • ^ 8 ^techniques. Forexampie.fhe**. 

relatively limited. The memory requirement ™^^™*£ZZ><ess* by the trusted display processor 260. a 
Lge could comprise: a ^' ess ^ Z£*Z£S generated by the trusted display processor 
thumb-nail image that forms the pnmit-ve t^*™^^^, which can be displayed by the trusted 
26fra naturally compressed image, such as a set of alphanume *»«*JJ" • |n m of these alternatives, 

^v^Sssor 260 as a single large image, or used as a m ^^Z^^ 26Q to decrypt the data before 
SSKaSZba in encrypted to^ 

?c^splayed.An^^ 
restored by ^ 

disply processor ^'^Z^^^^ nstructions) that couid be interpreted by an ap- 

SSfnS 5 snows the logical relationship ^ e "^^^^Vo?ration. Apart from .logical sepa- 
Socessor 260 and the smartcard 122. in the context of ^24^raM22hmcttons. the functions are represented 
STo host computer 100. trusted display P^^^^SSm^ of the processes which take part 
Wependentlydlhep* 
inafrustedsigningoperati^ 

a line x-y. where functions to the left of the lme are «£ c ^ ™ fof ^ duration of the signing process), on 
sented 7n ovals, and the "permanent" data <^"* *° data or received cryptographic keys an, not 

whfch the functions act, are ^J^SSST^^^ «* and ***** 
illustrated, purely for reasons of clarity. Arrows between ov 

logical communications paths. includes an application process 500, for example a 
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the mouse 115 to the application process 500; and a graphics primitives process 515 for generating graphics primitives 
on the basis o1 calls received Irom the application process via the API 511 process. The API process 511 . the keyboard 
process 51 3, the mouse process 514 and the graphics primitives process 515 are build on top of the operating system 
process 51 0 and communicate with the application process via the operating system process 510. 

s [0052] The remaining functions of the host computer 1 00 are those provided by the trusted display processor 260. 
These functions are; a control process 520 for co-ordinating all the operations of the trusted display processor 260, 
and for receiving graphics primitives from the graphics primitives process and signature requests from the application 
process 500; a summary process 522 for generating a signed summary representative of a document signing procedure 
in response to a request from the control process 520; a signature request process 523 for acquiring a digital signature 

10 of the pixmap from the smartcard 122; a seal process 524 for retrieving seal data 540 from the smartcard 122; a 
smartcard process 525 for interacting with the smartcard 122 in order to enact challenge/response and data signing 
tasks required by the summary process 522, the signature request process 523 and the seal process 524; a read 
pixmap process 526 for reading stored pixmap data 531 and passing it to the signature request process 523 when 
requested to do so by the signature request process 523; a generate pixmap process 527 for generating the pixmap 

is data 531 on the basis of graphics primitives and seal image data received from the control process 520; a screen 
refresh process 528 for reading the pixmap data, converting it into analogue signals and transmitting the signals to the 
VDU 105: and a trusted switch process 529 for monitoring whether the trusted switch 135 has been activated by the 
user. The smartcard process 525 has access to the trusted display processor's identity data Ipp. private key data 
and certificate Certop data 530. In practice, the smart card and the trusted display processor interact with one another 

20 via standard operating system calls. 

[0053] The smartcard 1 22 has: seal data 540; a display processor process 542 for interacting with the trusted display 
processor 260 to enact challenge/response and data signing tasks; smartcard identity data Iso smartcard private key 
data Sgc and smartcard certificate data Certgc 543. 

[0054] A preferred process for signing a document using the arrangement shown in Figures 1 to 5 will now be de- 

2$ scribed with referenco to the flow diagram in Figuro 6. 

[0056] Initially, in step 600,'the user controls the application process 500 to initiate a 'signature request' for digitally 
signing a document. The application process 500 may be realised as a dedicated software program or may be an 
addition, for example a macro, to a standard word processing package such as Microsoft's Word. In either case, neither 
the signature request nor the application process 500 need to be secure. When the user initiates the signature request, 

30 he also specifies the document to be signed, if it is not one which is already filling the whole screen. For example, the 
document may be displayed across a part of the full screen area or in a particular window Selection of a particular 
area on screen is a simple task, which may be achieved in several ways (using a WIMP environment), for example by 
drawing a user-defined box bounding the area or by simply specifying co-ordinates. 

[0056] Next, in step 602, the application process 500 calls the control process 520 to sign the image that is being 

35 displayed (within a defined area or window) on the screen; the control process 520 receives the call. In parallel, although 
it is not shown, the control process 520 receives any graphics primitives from the graphics primitives process and 
forwards them onto the generate pixmap process 527. The call from the application process 500 to sign a document 
includes the co-ordinates (a,b,c,d) of the edges of the document. Note that this sending of co-ordinates generaBy 
enables the signing of the entire surface of the screen, a complete window, or of an arbitrary part of the screen. The 

<o application process 500 then waits for the control process 520 to return the signature of the image. 

[0057] In response to the signature request, in step 604, the control process 520 forces the image that is to be signed 
to be 'static' from the time of the request until the process has been completed. Herein, 'static' means that the document 
image cannot be modified other than by the trusted display processor 260. This is so that the user can be certain that 
what he sees is what he is signing at ail times during the process. In the present embodiment, the control process 520 

45 achieves a 'static' display by 'hoWing-off, or not processing, any further graphics primitives. In some situations, the 
graphics primitives process (or equivalent) may 'buffer 4 graphics primitives until the control process 520 is ready to 
receive further graphics primitives. In other situations, graphics primitives for the image to be signed may simply be 
lost. Where the document image fills the whole screen, making the image static is simply a case not processing any 
graphics primitives. However, where the image to be signed forms only a subset, for example a window, of the full 

50 screen, the control process 520 needs to determine whether received graphics primitives would affect the 'static' area, 
and reject ones that would. As such, the pixmap of the static document image in the frame buffer memory 315 remains 
unchanged by any instructions from the graphics primitives process, or any other process executing on the CPU 200, 
while the document image is static. 

[0058] Once the document image has been made static, in step 606, the control process 520 instructs the generate 
55 pixmap process 527. including in the call the co-ordinates (a,b.c.d) provided by the application process 500. to modify 
the pixmap to highlight the document to be signed, as will be described in more detail below with reference to Figure 
10c. Then, in step 608, if a smartcard 122 is not already inserted in the smartcard 122 reader 120. as determined by 
the smart card process 525. the control process 520 instructs the generate pixmap process to display a graphical 
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COUNT. H the countdown timer expires (..e. reaches zero), as a resu application process 500. In 

-prjr:;^^^ in 6,ep 616 - 11 - smartcard 122 * 

Scard process 525. to recover the seal da^ ^ 

the Generate pixmap process 527 to display another message 'n^" 9 * 0 , msted dis p|ay processor 260 and the 

attempted^n steps 618 and 620, ^X^f^^™^^' **<TZ 
display processor process 542 of the sm^^^ , 

Sdata SEAL 540. The display processor process 542 ^^^^catena.es it with nonce R,. signs 
smarted process 525. The smartcard process 525 £ aerates ^ ^^ um s the concatenation R,!!^. 
me ^catenation R,!!^ 

display processor 260 is onlme. ^„ lion caused bv replay of old but genuine signatures (called 

[0061] The nonces are used to protect the user from deception caused by repay 

a replay attack') by untrustworthy processes. concatenates Ffe with Is seal data SEAL 540 

?00«5] The display processor process Mj^.--^ p ^ a Mature eS^USEAL). encrypts the sea. 
signs the concatenation R^ISEAL us«g its pnvate key^ to proouce^ jf ° { ^ L) , a nd sends nonce R* the 
daTa SEAL 540 using its private key S* to produce ^^^HicateCensc to the smartcard 

^^^^ 

524 to the control process 520. con roTAtvcs the seal data SEAL 540. it forwards 

^P^uming to Figure* in s^^^ 

LJtatothegenerate pixmap P^^^^^^X^^'^^^^^ 1 ^ 
35 and use it to highlight the document to be signed, as wU '^^™L g27 display a messa ge to the user asking 
Sep 624, the control process 520. instructs the ^ acSxnpanfed by a ten second countdown 

whaler they wish to continue with the signing °P°^™ ™3not reC eLg a response from the user, the 
timer COUNT. If the countdown timer expires, m step 2»£ a ^£, tton ^ to the application process 
control process cancels the signing operate «step628. and mturns an^ ep ^ ^ ^ ^ ^ 630i me 
* 500. In response, the applicat.cn process 500 JP^ 8 "* JJ^J te „ second time M the process continue^ 

45 signing'to occur. Such an alternatives are a ^^ t ^ h ^ ature requ esi process 523 to request the signtog 
[00641 Next, in step 632. the control process 520 "f^^JJJJ pbmp process 526 to request return ot a 
of the document image; the signature request process ^J^SEIK. 526 reads the respective pixmap 
digest o. the pixmapdataot me "^^^Ew^™^^***^^ 
data, uses a hash algorithm to generate a ^ JJ" * data' FD, which includes intonation 

50 process523.Addi.ionai^^ 

necessary to reconstruct the image from the pacmap ^ to ^«™ a|so t0 the sign ature request process 523. 
since the document text may not need to be '^T^^^m screen surface and their distribution^ 
For example, the display format data FD may J^dQgujnent is text-based) in the document (at 

such as -l 024 by 768'. and I the font typeanc 6 "°^J^ 
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[00651 According to Figure 8, the smartcard process 525 generates a request REQ2 for the smartcard 1 22 to generate 
a signature ot the digest D PIX and display format data FD. The display processor process 542 of the smartcard 122 
responds by generating a nonce R 3 and sending it to the smartcard process 525 with a challenge to return the digest 
Dp, x and the display format data FD. The smartcard process 525 concatenates the digest D PIX with the display format 

s data FD and nonce R 3 . and signs the concatenation D PIX IIFDIIR3 to produce a signature sS DP (D Plx llFDIIR3). The 
smartcard process 525 then sends the concatenation D PIX IIFDIIR3 and its respective signature sS DP (D Plx IIFDIIR3) to 
the display processor process 542 ot the smartcard 122. The display processor process 542 uses the trusted display 
processor's public key (which it has already received in the seal data 540 exchange) to verify the trusted display 
processor's signature s$d P (D P!X IIFDIIR3) and nonce R 3 , to prove that the digest is the current image digest The display 

•o processor process 542 signs the digest of the pixmap E? PIX and the display format data FD. using its private key. to 
produce two signatures sS sc (D PIX ) and sSsc(FD) respectively. The display processor process 542 of the smartcard 
then returns the signed digest sS^D^) and signed display format data sSsc(FD) to the smartcard process 525 of 
the trusted display processor 260. The smartcard process 525 next verifies the digest D P)X and display format data 
FD, using the smartcard's public key (which it already has as a result of the seal data 540 exchange), and verifies the 

*s smartcard's signature, to prove that the smartcard is still onfine. 

[0066] Returning to Figure 6. in slep 638, the smartcard process 525 of the trusted display processor 260 concate- 
nates the pixmap PIX. the smartcard's signed versions of the pixmap digest sS sc (D Plx ) and display format data sSsc 
(FD) to 1orm an individual signature PlXllsS sc (D PIX )llsS sc (FD) ot the image, and returns it, via the signature request 
process 523. to the control process 520, which returns the individual signature to the application process 500. The 

so application process 500 stores the individual signature, in step 640, and responds with a further call to the control 
piocess 520 to 'summarise the signing' operation in step 642. The purpose of a summary is to complete the signature, 
as will be described with reference to the now diagram in Figure 9 and also the example summary below: 



*S 1 TC-88503-00.01 

2 Access tame: Thu 06-May-1999, 11 : 18 

3 Pages: 2 

4 ImageOl I 560 x 414 (187,190) (1024 x 168] 
^ _____ BEGIN SIGNATURE -- * ~* 

£0 6 ^ftitUGoW2h6SLDgqQAvGZZY47Fp8wx5ZqE5HS8bGrSV3RD7LKw0kyXPY6yhGDpVNUc/R2 

+Gr4im0LqS/twYuPdskyL4uk3no0w3LG2+f+/v2C4cKMPeY/L^bazZScvhK3CJ+apQxyik] 
cY5rTC563klov0PTBI/lyqZPxRnic- 

7 END SIGNATURE 

8 Image02 | 670 x 379 (201,228) [1024 x 768) 

35 9 BEGIN SIGNATURE , _ i ^_ jCW , ^ 

10 UVlw5Rgr5F0iAjvUW4GP28NKAA+tOy42uBbP78JeQ5w20MIlafTYkSNtfn9VykYMPIfZLwM 



40 7ZZV+4fFttuSgOZI4n5iBkSEwtEj0z6ik/np6paq+01GQZhhJCbq8OaX97Gmdg3AoBq4x+D 
hujmqkCJO+Dz6+x8kE24Z8YFXLPOI* 
X! END SIGNATURE 

12 Summary signature: 

13 ——BEGIN SIGNATURE"""™' —— 

45 14 c7zDZL2 + 41FsFci2cPjWFsfltkyXrfHBUM 

een2DWlZGjplEESNkhoZXjOkT5TYNv2ylYFk01SN+JVF09bmc9GdYLo/hSOWyYG/U29M2qz 

ktaTdTqY/gPhlGajrSJGqRms+we/c« 



so 



aTdTqY/gPhlGaj 
15 END SIGNATURE 

[0067] In step 644, the control process 520 calls the summary process 522 to generate a summary message SUM 
containing the number of images (two in the example summary above) plus the individual signatures of the images 
(lines 6 and 10 of the example), a label identifying the trusted display device (line 1 in the example), the current time 
and date (line 2 in the example) and a signed digest of the summary itself (line 14 in the example). For each image, 
the summary also includes the size of the image in pixels (e.g. 560x41 4 for image 1 ), the offset from the origin of the 
screen in pixels (e.g. 187,190 for image 1) and the display resolution in pixels (e.g. 1024x768 for image 1). 
[0068] The summary process 522 then generates a digest of the summary D SUM in step 646 and calls the smartcard 
process 525 ol the trusted display processor 260 to interact with the smartcard 1 22 using challengetesponse processes 
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as will now be described with reference to Figure 9. 
to generate a signature of the 8 ^^t^^en^tesa request REQ3 for the smartcard 1 22 to generate 
[0 669] AccordingtoFmumVhesmar^^^^ 

L a signatureof the digest of the sundry ^u^^^J^. The smartcard process 525 concatenates 
R 4 and sends it in a challenge to return thed.gest * ^ swnmary JJ" ^ uce a signature sSopffWI^)- ^ e 
Z tf-gest D SUM wiU, nonce D SUM ..R 4 and respective 
smartcard process 525 of the trusted display p «** s » r j^ ™ • process 542 then venfles the 

signature to the ^ ^,£^3* ««^ P«* ■«* «"** « a,ready 

trusted display processor's »^»^^^Z$^*tocZZ summary. Next, the display processor 
has from the seal data 540 ex^nge) to prove that »J£JW^ and ^ „. sign ed digest sS^um) to 
process 542 signs the digest of the summary D SUM using ^ ' ^ processor 260 verifies the digesf and 

the smartcard process 525. The ™™«J>™*f 6 ^pSe that the smartcad is still oniine. 

aW" P^^TSl^ P-ss 500. or any other process 

of graphic primitives associated with the J^^^SSSS ^may not be handed bacK to the appfi- 
the application process 500 o, other ^^^^^^^^^ m response to another user message, 

SSI™ 
Slxeretom^ 

[0073] In order to verify a signed document ^"fT^L^ * ^ known to those skilled in the art olsecunty. 
LrySUMnsSscftW ^^J^^^J^^S^^ «he public key of the user, which 
For example, the signature on the d,gest a J^^S£S^m Cert- supplied by a certification authority. The 

r00761 In the preferred embodiment, the seal data SEAL ^P ®^ * P .™000 Figure 10b illustrates an image 
sX in Figure'lOa. the pixmap of the seal data ^^%^^^SU As afirst highfighting 
100 5 of an exemplary documentDocl to be the trusted display processor 

step, after the image has been made etaucl "JSSbSlSS around the document image 1005. as tflus- 
260 highlights the document to be stgned by ™g™^Z^™ J£ 1 030 asking the user to insert he 

trated in Figure 10c. Also, where ajrmrtcard ^*^^ a ^ ox> as also illustrated in Figure 10c. Next, 
smartcard is displayed accompan.ed by a ten second ™ usted display proceS sor 260 embellishes 

Zm the smiley face pixmap image is <^J™^^™^JZ in Figure I0d. In addrtio, as 
the frame 1040 with multiple instances 1045. or a mosaic «*J™J V"' me 10 50. accompanied by a 
shown in Rgure lOd. the tourted dtepjy "^KjlSJS^^ Process. This em- 

len second countdown timer 1055. asking the ^^^SiW * bring acted on and provides the 
MM frame 1040 both indicates to the user that _ JJ«2SS5 ! fully in control of the signing process; the 
user with a high level of confidence thai ^^^Zm^*^ the message has come from the trusted 
presence of the usef s own seal .mage prwKtesc^fid^totne u^r ljcation or hardwar e device, 

display processor 260 rather than from some other J^TJ ^ Ho6 Tated in Figures 10c and 10d. In 

Sn Figures 10e and I0g ilfustrate alternates tolhe , m m*u- effect rt* ^9 ^ ^ 

Figure I0e four singfe seal images 1060 are gjj^^^^i. in Figure 101. the static image is 
ordinates provided by the application process iBOOjo "JjJ^J^J* Figufe t^the static image is defined 
defined by modify^ the background ^SLTS-^ ** »» ski,ted ' eader ^ ^ 
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addition, it may be desirable to include further status messages during the signing operation, for example "Retrieving 
seal data 540 now....*, 'Generating document signature now....*, etc. 

[0078] It will be appreciated that the trusted display processor 260 needs to be able to display the seal image(s) and 
the messages in the correct places on screen. Clearly, the seal image and the message images are temporary, to the 

5 extent they appear during the signature process and disappear thereafter. There are well-known, standard display 
techniques for overlaying a first image with a second image, thereby obscuring a part of the first image, then removing 
the second image and restoring the portion of the first image that had been obscured. Such techniques are used as a 
matter of course in normal windows environments, for example, where multiple windows may overlap one another. 
The trusted display processor 260 is arranged to implement one of more of these standard techniques for the purposes 

io of superimposing the seal image(s) and the message images over the standard display. 

[0079] In some scenarios, il may be that a document' is too large to fit all at once onto the VDU 105 screen and still 
be easily read by a person. Obviously, for the present embodiment to be practical, it is essential that a user can very 
clearly read the document before signing it. Therefore, the document can be split into multiple screen pages, each of 
which needs to be signed and cryptographically chained to the signature of the previous page, as will now be described. 

is [00801 First, the application process 500 causes the image of the first page to be displayed and makes a call to the 
trusted display processor 260 for signing as belore. When the trusted display processor 260 returns the individual 
signature, instead of requesting a summary, the application process 500 instructs the trusted display processor 260 
to display the image of the second page and sign the image. Clearly, in this case, the trusted display processor 260 is 
arranged to support such a request by the application process 500. Only after all Images have been signed and returned 

20 to the application process 500 does the application process 500 issue a request lor a summary. Then, the summary 
includes the number of images that were signed in this multi-page document, for example as illustrated in the two- 
page summary above. 

[0081] The first page in the multi-page document is signed in the same way as a single page, resulting in return of 
an individual signature. When subsequent images are presented for signing, however, the trusted display processor 
260 recognises that thoy are part of a multi-page document because no summary request was received after the 
previous signature request As a result, the trusted display processor 260 displays a different message, which requests 
permission from the user to sign a continuation page. In response, the user who is signing a multi-page document uses 
the same reliable permission channel as before (for example, the trusted switch 1 35) to confirm to the trusted display 
processor 260 that this page is associated with the previous page, and is also to be signed. When the trusted display 
so processor 260 receives this multi-page confirmation, it concatenates the signature of the previous signed page with 
the pixmap of the current page, creates a digest of the concatenation, and sends that to the smartcard for signing. This 
is instead of sending a digest of just the current pixmap. This process cryptographically ■chains' a subsequent page to 
the previous page, so that pages cannot be rearranged without detection, nor can intermediate pages be inserted or 
deleted without detection. 

55 [0082] The validity of the first page may be checked in exactly the same way as a single page. The validity of sub- 
sequent pages is checked using the same method as for a single page, except that the digest of the current pixmap 
is replaced by the digest of the concatenated previous signature and current pixmap. 

[0083] It will be appreciated that there are many ways of cryptographically chaining a subsequent page to a previous 
page. Such ways will be obvious to those skHled in the art of security in the light of the present description. 
40 [0084] For added security, the image of each page of a multi-page document may be arranged to include the con- 
ventional footer 'Page x of y, where V is the number of the page and y is the total number of pages. This enables 
ready detection by a person of a truncated document simply by reading the document. 

[0085] A significant benefit of the present document signing scheme is that a signed document can be resigned and 
countersigned. As such, it is preferable lor the summary of a document to include an audit trail. There are many van- 
's ations on re-signing and countersigning, although (obviously) an electronic integrity check should always be done 
before any further signing. At one extreme, the new signer could view, confirm and re-sign each signed image in turn, 
effectively replacing the original signature by a new one. This method could be used, tor example, by a user signing 
a document prepared for him by someone else. At the other exlreme s the new signer could simply 'rubber stamp 1 the 
original signature by signing the original summary, without necessarily viewing the document at all. This could be useful 
so to a manager countersigning the work of a trusted employee. 

[0086] For a re-signing operation, the application process 500 issues a re-signing request, and transmits an already 
signed document (plus the individual signature(s) and the summary) to the trusted display processor 260. The trusted 
display processor 260 verifies the signed document using the public key of the signer, recovers the pixmap of the 
document (or each page of the document) and displays each verified image in the correct order to the new user, as if 
ss they were original images from the signature request application. The user confirms the acceptance of each individual 
image, for example using a trusted switch 1 35 as before, and causes the images to be signed as before by a smartcard 
belonging to the new user. This results in a signed document that is the same as the original document, except that it 
has been signed by the smartcard belonging to the new user. 
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■ ^^t™ the aoolication process 500 issues a counter-signing request and 
[00871 Similarly, for a counler-s.gning operation, the apP^'^ P ^ ^ tf ^ processor 260. The 

LsL the signed document (plus MM** ^^ a ^ d ^^ef^ga in M correct order to . 

parent to the skilled person in the light ot the present description^ . e , efnbodime nt 

£>«,] ShceadocumerttmayhaveahWfsignjn^ , 
convenient* provides audit information, ^^^J^^Sl' about the previous state of the 
signature history of the document to be traced. The audrt ,n '^ t '^^ J^ ument . The audit information is 
dement and the actions taken by the new user t .create the ™ w ^X^pendent of the use, The audrt 
signed by the trusted display processor 260, 8 ^^^J^7^2^n*at summary information, 
information always contains any previous summa* in ^Sjl ,^ i^SThe identity label !„, of the trusted 
by me previous signer). If the signed documerrt ha* been ^^STly So inSurL an Mtertion of wttch 
dUyprocessor260isinse«edasanaud«^ 

individual images were viewed and confirmed by the new user art ^ rmU ^^toesnanca*i 
orvrasre-sfcned.c^wascoun^ 

is sent a digest ol the audit inlormatcn pr0C8S s is as previously described, 

a digest ot just the previously described ™ x ^«* s ZZSs Zt pri^o S the pbcmap data, the trusted 
10090] An enhancement to the process for sign^g a %^J^^*J>™«> .hat the ovemeads associ- 
display processor 260 compresses the pixmap using a lossless compression »u 

ated with storing and sending the individual signature are reduced codoworf-based algo- 

I0 09U The pblmap may be compressed by standard <™^™^^\^Tz^r recognition) may 
ithm applying LZ-1 or LZ-2 compression. Attentive* ^^f^^^^^^t^MB^ . 
be usedto compress the pixmap. In this case the s uaton ^ZSa CcS^ompressed version o. the 
been perfectly 'scanned", albeit at a lower resolut.cn than .n a pb( map ot each 

pixmaP may be generated by -blob-matching' to create an ^^"^^^Sta mesLge represents the 
chafer to the alphabet, and constructing a message ™W*>***™^> £^£ m me8S £ B written in that 
orig«al pixmap. This means that the pixrru* can be^ ^ 

alphabet. Since there are. obvious*, noerror* >nor ^^^^^^^Bsa^febtockana^ 

tor colour documents or images. hark into - tex i-based document using an OCR-type 

[0093] At any time, the document image may be converted back ' i ^™^ technk ^ b e used in the 
process to reconstruct a standard digital text ual nf"-^ * ^^^VoS s^ dlocument to convert 
Signature, since the textual ^^nS^ 

it back into a standard digital textual represented* ^^^^"^o^^ument recovery. 

embodiments, the trusted display processor 260 « equ ^J^^J^^ ^ed to stored fonts and 

[0094] To enact OCR. an OCR alphabet is generated tn "**J^"^ou, etches may be retained as a 

dttac«nn« be raffled unless the trus^^^ 
[0097] ,,*,.beappre^ted^ 

architectures are arranged such that the frame b ^ er J Z. at ^ ^ CPU and the display processor 
address space (SAS) dispfay system. One benefit ^^^^2 ^ improving graphics perform- 
can access the Irame buffer memory and share he ^^^f^™*^™^ re Jonthe premise that the 
ance. Clearly, an implementation of the present invention in such a SAS system cannor v 



14 



BNSDOCID: «EP_I0S6014A1.I.» 



EP 1056 014 A1 

buffer memory is safe during signing, since the CPU can still access the memory. However, there are many ways in 
which such a SAS system may be modified to support implementations of the present invention. For example, the 
memory could be provided with a control line from a trusted display processor such that, during a signing operation, 
the memory is prevented from being updated by data from the CPU. The memory devices themselves are preferably 

5 modified so that they include the extra logic to perform this function. Alternatively, access to memory is blocked by 
other logic circuits inserted into the normal control path of the memory. Such systems, therefore, rely on the modified 
premise that the video data in the frame buffer memory can only be modified, other than by the trusted display processor, 
with Ihe permission of the trusted display processor. Clearly, this premise is as valid for secure operation as the first 
premise, as long as the system is truly secure. 

10 [0098] In other architectures, for example in simple graphics environments, the functionality of a display processor 
may lorm part of the operating system itself, thereby removing the requirement for separate display processor hardware. 
Clearly, in this case, the graphics overhead put on the CPU will be higher than in a system with separate display 
processor hardware, thereby limiting the graphics performance of the platform. Clearly, there is then no place for a 
trusted display processor* as such. However, it will be apparent to the skilled person that the same function as provided 

is by the trusted display processor, that of protecting the frame buffer memory and interacting with a smartcard. can be 
implemented using an appropriate trusted component, which controls the display system (in whatever form) during 
signing. 

[0099] In other embodiments of the invention, in addition or alternatively, the trusted display processor (or equivalent) 
includes an interface tor driving a trusted display. The trusted display might be, for example, an LCD panel display. In 

20 the same way that the trusted switch provides a trusted means for a user to interact with the trusted display processor, 
the trusted display can provide a trusted means for feeding back information to the user other than via the standard 
VDU. For example, the trusted display might be used to provide user status messages, as described above, relating 
to a signing operation. As such, applications running on the standard host computer should not be able to access the 
trusted display, because the display is connected either directly to the trusted display processor or via some form of 

2S trusted channel. In essence, such a trusted display is an addition to the so-called trusted interface' described above. 
In practice, there is no reason why other forms of trusted feedback device, of which the trusted display is one example, 
could not be included in addition, or as an alternative. For example, there may be scenarios where some form of trusted 
sound device would be useful for providing audfole feedback. 

[01 00] An alternative application for the invention is to provide a trusted interface during an electronic transaction. 

so In one exemplary embodiment, the user wishes to send sensitive data to a remote computer system. The user cannot 
be sure that the remote computer system, or indeed the host computer he is using, is trustworthy. In order to ensure 
that the sensitive data is safe from interception by unauthorised parties during transmission to the remote computer 
system, and to ensure that only the authentic remote computer system can read the sensitive data when it is received, 
the user wishes to encrypt the data using the authentic remote computer system's public cryptographic key. In the 

35 embodiment, the host computer incorporates a trusted component, which interacts with the user's smart card in order 
to recover and display a trusted image as descrfoed in detail above. The trusted image may be displayed on the 
standard VDU screen or on a separate display, such as an LCD display, in order to indicate to the user that the trusted 
component, rather than a subversive application, is in control. The trusted component then interacts with the remote 
computer system in order to recover and authenticate the remote computer system's certificate containing a respective 

#> public key. With the public key, the trusted component encrypts the sensitive data, which might itself also be read from 
the smartcard, and transmits the encrypted data to the remote computer system. 

[0101] There are many other applications, especially e-commerce applications, where the concept of a trusted user 
interface, providing trusted user feedback and trusted user input devices), would be valuable. As such, the present 
invention should not be read as being limited to the few embodiments described above, and should only be limited by 
<s the language of the claims. 

Claims 

so 1 . a data processing system capable of operating in a trusted operating mode, the data processing system compris- 
ing: 

main processing means for executing at least one application process; 

a trusted component comprising means for executing a trusted process in a trusted operating mode and means 
ss for generating user feedback signals; 

at least one user feedback device; and 

user feedback processing means for receiving said user feedback signals and controlling the user feedback 
device on the basis of the signals. 
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operating mode, 
trusted process. 

A data processing system according to claim 1 or claim 2. wherein: 

the ma* processing means includes means to execute at .east one application process and generate signals 

Herf^^ 
Xret« 

SSSSssssssr 

main image as being associated with execution of the trusted process, 
the data processing system is executing the trusted process. 

acteristic of at least a portion ol the mam image. 

9. Adafcproce^inflsys^ 
to verity the identity of the secure token. 

10. A data processing system according to any one ol claims 4 to 9, wherein the secure token comprises means to 
verify the identity of the trusted component. 

11. A data process^ system accord*, to any one c4 da^s 4 to 10. where, each ot the trusted component and the 
46 secure token include non-volatye memory. 

Sata and/or verily that the encrypted data was encrypted us.ng the correspond^ pubis key. 

• i a wherein the data characterising the trusted image 
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the data. 

16. A data processing system according to any one of claims 4 to 1 5, wherein the data characterising the trusted image 
is stored by the secure token in encrypted form and the trusted component comprises means to decrypt the data 

5 and/or verify that the data was encrypted using a corresponding encryption key. 

1 7. A data processing system according to any one of claims 4 to 1 6, wherein the data characterising the trusted image 
comprises a series of instructions and the trusted component comprises means to interpret the instructions in order 
to generate the trusted image data. 

10 

18. A data processing system according to claim 6. wherein the trusted component controls the display processing 
, means to highlight the main image, or portion thereof, by producing one or more of the following Visual effects: 

a border, or an indicator (or indicators) defining a border, characterised by the trusted image and placed at 
15 least partly around the main image or portion thereof; 

a background pattern characterised by the trusted image forming at least part of the background of the main 
image or portion thereof; 

an image characterised by the trusted image formed within the main image or portion thereof; and/or 
a text message characterised by the trusted Image formed within the main image or portion thereof. 

20 

19. A data processing system according to any one of claims 3 to 1 8, wherein the display processing means comprises: 

frame buff er memory; 

a pixel generator to generate pixel data representative of the main image on the basis of the signals received 
2S from the main processing means; 

a frame buffer refresher to update the pixel data in the frame buffer memory; and 

a video controller to repeatedly read the pixel data from the frame buffer memory, generate signals suitable 
for driving the visual display unit and transmit said signals to the visual display unit to display the image, 
and wherein the trusted component comprises means to write the trusted image data, or data derived from 
30 the trusted image data, to at least a portion of the frame buffer memory in order to combine the further image 

with the main image. 

20. A data processing system according to any one of claims 3 to 19, wherein the trusted component and the user 
feedback processing means are embodied in a single application-specific integrated circuit or as an appropriately 

35 programmed microcontroller. 

21. A data processing system according to claim 2. wherein the trusted process comprises plural steps and at least 
one of the steps is initiated by user interaction with the trusted component via the secure user input means. 

40 22. A data processing system according to any one of the preceding claims, wherein the trusted component is tamper- 
resistant. 

23. A system comprising: 

*5 main processing means for executing at least one application process; 

means for executing a trusted process in a trusted operating mode and means for generating user feedback 
signals; 

at least one user leedback device; and 

user feedback processing means for receiving said user feedback signals and generating respective signals 
so for driving the user feedback device, 

wherein the means tor executing the trusted process comprises means to control the user feedback processing 
means to cause the user feedback device to provide an indication that the data processing system is operating 
in a trusted operating mode. 

55 24. A method for providing a trusted user interface in a data processing system, comprising; 

executing a secure process and generating respective user feedback signals; 

providing user feedback on the basis of the user feedback signals in such a way to indicate that the data 
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processing system is operating under the secure process 
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